by Robert Stowsky | March 8, 2004 |
The recent announcement by FIX Protocol Ltd. (FPL) on its certification program for fixed income highlights an ongoing debate not isolated to the financial services industry. On one side of the debate are those who see standards as a way to promote common industry practices. On the other side are those who think standards can dampen innovation. Somewhere in the middle are the people who participate in industry organizations to create these standards. They must walk a fine line between the two sides to build standards that are both usable and flexible in order to be adopted by their intended target communities. How stringent, or how flexible, a standard should be depends on both what is being standardized
and who will use the standard.
As the FIX protocol expanded to include support for fixedincome trading, participants in the market, whether from the buy-side, sell-side, trading platform, or product vendor segments of the industry, began to take sides in the debate. Surprisingly, what side is taken is not a reflection of a participant’s particular role. In separate conversations with two leading buy-side firms, I was given two very different points of view. The head fixed-income trader of the first firm welcomed the addition of the expanded support of fixed income to the FIX protocol with a caveat: He did not want to see the amount of variation in how the protocol was implemented that he had witnessed on the equity side of the business. The second firm also welcomed the FIX protocol’s support for fixed income, but it had quite a different caveat: Its fixed-income trading department wanted the protocol to allow them to add information to certain messages that they felt was necessary for how they traded with their counterparties.
On the other side of the trade, both sell-side firms and trading platforms are equally split in their desire for a strictly adhered to standard versus one open to creative modification. By having a strictly enforced protocol, firms only have to develop a single implementation for all of their clients. However, a flexible protocol allows firms to differentiate themselves from competitors by enriching the contents of the messages. For vendors of order management systems that need to both generate and consume messages, a single flavor would ease both product development and support. Most of the major FIX engine vendors support the ability to add user-defined fields without the need to modify the FIX engine itself, making them the few agnostics in the debate.
Business Process Dictates Flexibility
Other protocol standards for the investment industry face similar dilemmas. Where they fall in their requirements for strict adherence and malleability is often a reflection of the processes they are supporting. The Financial product Markup Language (FpML) is designed to support the OTC derivative market. This is a market that is driven by innovation and flexibility. While FpML offers a prescribed format for describing various OTC deals that corresponds to the master agreements provided by the International Swaps and Derivatives Association (ISDA), users can make extensions and deletions as they see fit to correspond to their particular business needs.
The Market Data Definition Language
(MDDL) provides a standard format for describing listed financial instruments, indices and events, such as corporate actions. MDDL describes both the static data, such as who issued a particular bond, as well as the dynamic data, such as the current price for a stock. As the basic content for this type of information is fairly well agreed upon by both the producers and consumers of market and pricing data, MDDL can provide a standard more rigid than others. Yet MDDL also is extensible enough to accommodate additional data that an exchange may want to provide as well as enrichment from data vendors.
Likewise RIXML, the Research Information Exchange Markup Language for the distribution of market research, provides a solid framework while allowing users to add or delete information. By providing a combination of design rules and data definitions, ISO 15022 is looking to provide a repository flexible enough to build messages for any financial related process.
Enforcement Evolves Over Time
At some point one would expect that these standards’ flexibility would interfere with the goal of providing a common method of exchanging and storing information. If we make enough modifications can we actually say that we are using a particular standard? To put it another way: Is there a point where we can no longer say we are compliant to a particular standard whether it be FIX, FpML, MDDL, or RIXML?
How a standard is enforced falls into the two categories of user enforcement and organizational enforcement. User enforcement can further be divided into accepted practice and best practice. Organizational enforcement can be split into validation and certification. How a standard is enforced is often a reflection of its acceptance and maturity. In its early stages, a standard will usually have a specification that is open to interpretation. During this period we begin to see accepted practices that are agreed to between specific counterparties.
As the standard is adopted, a trial and error phase usually points to areas requiring more rigorous definition. A tighter definition of a standard combined with a larger base of users commonly results in community recommended best practices. When a standard has reached both a broad level of acceptance and a high level of complexity the user community will often call upon the organization overseeing the standard to provide some method of arbitrating differences of interpretation that still may arise.
Certification Vs. Validation
Standards organizations have a number of choices in how they can enforce the standards they oversee. The FIX and FpML standards each provide an example of how to promote common implementation of their protocols by using a different approach respectively. FPL has embarked on a somewhat centralized certification program to assure conformance to the FIX protocol for fixed-income users. ISDA, which oversees the FpML standard, has taken a more distributed approach by providing its users with a set of rules for validating the proper use of the standard.
FPL has selected vendors who will be recognized certification agents for the protocol. These agents will each implement a set of test scripts to be provided by FPL. In order for a firm to say it is FPL certified, it will need to run through a series of tests with a certification agent that covers the various asset classes and message dialogues for which it wishes to claim certification.
For FpML, its Validation Working Group has created a set of rules for users to implement on their own. The Validation Working Group offers a reference implementation of the validation rules and test cases for users to model their own implementations on. A user would send an FpML document to a counterparty that contains a field that would reference the set of rules for which the document
is claimed to be valid. The counterparty would then be able to validate the document against the stated set of rules and accept, or reject, the document. Counterparties could also agree between themselves on customized subsets or supersets of rules to determine validation.
The choice of certification versus validation reflects the respective environments in which these standards are used. By definition, certification is focused on the operational aspects of a protocol. From an operational point of view it is not enough to only know that the message contents are correct, but also that it is the right message being sent. If I request a quote and you respond with an execution, we have a problem, regardless of whether the messages themselves are formatted correctly. Certification makes sense
when you have an ongoing dialogue between parties as you do when using the FIX protocol. Validation is focused on the content itself. FpML provides an electronic representation of an agreement between parties. Validation ensures that all the necessary data is there and in the right place. Both certification and validation provide a method for testing and verifying that a minimum set of requirements is met in order to claim compliance to a standard.